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Section  One 
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Introduction 


Automated  Interactive  Simulation  Modeling  System 
(AISIM)  is  an  interactive,  graphics-oriented  mod¬ 
eling  system  capable  of  simulating  a  variety  of 
problems  ranging  from  user-machine  interfaces  to 
distributed  computer  systems.  It  uses  interactive 
graphics  to  specify  a  system’s  architecture  and  to 
describe  the  functional  processes  that  operate 
within  that  architecture.  AISIM  produces  plots 
of  performance  statistics  for  messages,  system 
resources,  and  system  functions.  Reports  include 
queuing  (time  in  queue,  queue  length),  resource 
usage,  and  message  transit  time  statistics.  Row- 
charts  of  a  model's  logical  processes  are  automati¬ 
cally  produced  providing  an  excellent  source  of 
model  documentation.  AISIM  runs  under  the  IBM 
MVS/TSO  and  the  VAX  VMS  operating  systems. 


AISIM  is  designed  to  be  particularly  useful  during 
the  conceptual  design  phase  of  Command,  Control, 
Communications,  and  Intelligence  (C3I)  system 
acquisitions.  It  is  useful  for  the  design  and  analysis 
of  computer-based  systems  including  local  area 
networks,  data  processing  systems,  and  distributed 
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systems.  It  can  be  used  to  perform  sizing  and 
timing  studies  in  the  development  of  software 
and  hardware  designs,  system  architectures, 
and  protocols.  AISIM  supports  the  preparation  of 
specifications  by  quickly  providing  answers  on  the 
technical  feasibility  and  impact  of  performance 
requirements.  It  can  also  be  used  to  validate  the 
performance  of  proposed  designs.  While  a  system 
is  being  built  or  after  it  becomes  operational, 
AISIM  can  be  used  to  model  proposed  changes 
and  enhancements  in  order  to  determine  cost- 
effective  solutions. 


AISIM  is  an  easy-to-iearn  tool  that  can  be  used 
directly  by  an  analyst,  thus  eliminating  the  time- 
consuming  and  error-prone  interaction  between 
analyst  and  simulation  programmer.  AlSIMs  high- 
level  representative  language  facilitates  the  prep¬ 
aration  of  a  model.  AISIM  modeling  constructs 
correspond  to  those  of  the  system  being  modeled, 
resulting  in  a  mapping  relationship  between  AISIM 
entities  and  those  of  the  modeled  system  (figure  1). 
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Using  the  Architecture 
Editor,  the  User  “DRAWS”  the 
Network. 


Using  the  Process  Editor,  the 
User  “DRAWS'  the  Function 
Flowcharts. 


Using  the  Analysis  Interface, 
the  User  Defines  Plots  to  be 
“DRAWN.” 


Figure  2 

Interactive  Graphics 


A  networks  physical  architecture  is  represented 
by  using  AlSIM’s  architecture  design  feature.  The 
physical  resources  of  the  modeled  system  are 
depicted  graphically  on  the  terminal  screen.  The 
logical  processes  of  a  system  are  represented  by 
A1SIM  entities  called  processes.  Processes  con¬ 
tain  elements  called  primitives  that  correspond 
to  steps  in  the  modeled  system’s  logic.  The  hard¬ 
ware  resources  of  the  modeled  system  are  rep¬ 
resented  one-for-one  by  AISIM  entities  called 
resources.  AISIM  also  provides  items  that  repre¬ 
sent  transient  data  elements,  such  as  messages, 
that  can  flow  through  a  modeled  network.  This 
correspondence  between  system  components  and 
AISIM  entities  simplifies  the  model  builder’s  task. 


AlSIM’s  interactive  graphics  assists  the  analyst  in 
several  modeling  areas.  Of  the  three  examples 
shown  in  figure  2,  the  first  illustrates  AlSIM’s 
capabilities  that  enable  the  user  to  “draw”  the 
modeled  architecture  on  the  screen.  The  second 
shows  model  processes  represented  in  the  form  of 
a  flowchart  called  a  process  diagram.  As  the  user 
builds  a  process,  this  flowchart  is  drawn  automati¬ 
cally.  The  third  example  illustrates  AlSIM’s  plot 
output.  AISIM  provides  statistical  plots  for  perfor¬ 
mance  attributes  of  system  resources  and  mes¬ 
sage  transactions.  Performance  measures  such  as 
throughput,  response  time,  resource  usage,  and 
queuing  may  be  viewed  as  plots  at  the  completion 
of  a  simulation. 


These  are  only  a  few  of  the  capabilities  made 
possible  by  AlSIM’s  five  functional  interfaces.  The 
next  section  describes  each  of  these  interfaces, 
and  the  final  section  gives  examples  to  illustrate 
AlSIM’s  model  building  and  execution  features. 
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Section  Two 


AISIM  Interfaces 

AISIM  consists  of  five  functional  interfaces  as 
shown  in  figure  3:  Design,  Analysis,  Replot,  Hard¬ 
copy,  and  Library.  The  Design  Interface  (Dl)  pro¬ 
vides  the  user  with  the  commands  necessary  to 
design  and  construct  a  model.  The  model  is  actu¬ 
ally  run  or  executed  using  the  Analysis  Interface 
(Al),  which  provides  the  commands  necessary  to 
control  the  simulation  and  view  simulation  results. 
The  Replot  Interface  (Rl)  allows  the  user  to  view 
plots  from  different  runs  and  to  plot  them  on  the 
same  graph.  The  two  remaining  interfaces,  the 
Library  Interface  (LI)  and  the  Hardcopy  Interface 
(HI),  provide  tools  for  model  documentation  and 
for  saving  models  to  be  used  in  subsequent 
studies. 

Design  Interface 

In  creating  a  model,  the  DI  is  used  to  describe 
the  modeled  system's  functions  and  architecture 
through  a  set  of  constructs  called  entities  (table  1). 
The  DI  is  used  to  select  and  enter  the  required 
entities  into  a  model.  It  contains  commands  for 
creating  and  modifying  model  elements  including 
the  architecture,  the  processes  that  describe  the 
model  logic,  and  the  external  system  loads.  Other 
model  entities  include  model  resources  not  defined 
in  the  architecture,  and  entities  such  as  tables, 
constants,  and  variables. 

Most  entities  are  created  using  the  edit  command. 
This  command  causes  a  form  to  be  displayed  for 
the  entity  being  defined.  When  a  form  is  com¬ 
pleted  and  entered,  the  defined  entity  becomes 
part  of  the  model.  Forms  help  the  modeler  enter 
data  correctly  and  ensure  that  all  necessary  data 
is  included.  Forms  also  facilitate  quick  model 
building  and  reduce  the  probability  of  errors 
being  introduced  into  the  model.  Creation  of  the 
model  architecture  and  model  processes  are  com¬ 
plex  functions  that  make  use  of  graphics  as  well 
as  forms.  These  and  the  means  used  to  define  the 
load  on  the  modeled  system  are  discussed  below. 

Architecture  Editor  (AE)  The  AE  is  used  to 
create  the  system  architecture  in  graphic  form 
(figure  4).  It  displays  the  layout  and  interconnec¬ 
tions  of  the  physical  elements  of  the  modeled 
system.  Arbitrarily  chosen  symbols  represent 
physical  system  elements.  The  lines  or  links  con¬ 
necting  them  represent  communications  paths. 
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AISIM  Interfaces 
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Figure  4 

HOHE  ■  LEFT  0 ,  UP  6  Architecture  Example 


ARCHITECTURE  LEGAL  PATH  DEFINITION 


FROM 

TO 

NEXT 

VIA 

DEVICE 

DEVICE 

DEVICE 

LINK 

X33»S38 

SSS3319: 

=  =  s;=:=  =  : 

HI 

HI 

SI 

Hi  SI  A 

HI 

B2 

SI 

BISt  A 

HI 

B3 

SI 

HiSi  A 

HI 

B4 

SI 

HISi  A 

HI 

HS 

SI 

HiSi  A 

HI 

H6 

SI 

HiSi  A 

Figure  5 

Legal  Path  Table 


For  each  node  and  link,  AISIM  creates  a  resource 
entity  to  which  attributes  may  be  assigned.  The 
AE  can  also  create  a  Legal  Path  Table  (LPT), 
sometimes  referred  to  as  a  routing  table,  from  the 
architecture  diagram.  Figure  5  shows  part  of  the 
LPT  for  the  architecture  of  figure  4.  The  LPT 
contains  the  paths  or  routes  to  be  used  between 
each  pair  of  nodes.  An  entry  in  the  table  consists 
of  four  elements:  the  FROM  node,  the  TO  node, 
the  NEXT  node  on  the  path,  and  the  next  LINK 
on  the  path.  The  LPT  is  used  by  model  processes 
to  route  messages  through  the  modeled  system. 

Process  Editor  (PE)  The  functions  of  a  mod¬ 
eled  system  are  described  in  AISIM  by  processes. 
The  PE  creates  and  modifies  processes  and  dis¬ 
plays  the  elements  of  a  process  as  a  flow  diagram 
(figure  6).  Each  functional  element  is  called  a 
primitive  (table  2).  Easy  to  learn  and  use,  the 
primitives  are  the  only  “language”  the  user  must 
learn  in  order  to  build  models  in  AISIM. 

Scenario  and  Load  Entities  The  scenario 
and  load  entities  are  used  to  define  the  model 
environment  in  the  form  of  information  and  data 
passed  to  it.  The  scenario  (figure  7)  allows  the 
analyst  to  specify  the  number  of  time  units  per 
simulation  period  and  the  number  of  periods  in 
the  simulation.  Breaking  the  simulation  run  into 
periods  provides  the  analyst  with  the  flexibility  to 
examine  intermediate  results.  The  scenario  is  also 
used  to  specify  one  or  more  loads,  and  the  time 
and  priority  to  trigger  each. 


Figure  6 

Process  Flow  Diagram 


The  load  (figure  8)  permits  processes  to  be  sched¬ 
uled  cyclically  or  repetitively.  It  is  used  to  schedule 
processes  that  create  items  (messages)  which 
represent  external  loads  or  inputs  to  the  system. 
The  load  identifies  the  rate  at  which  processes 
will  be  scheduled  and  items  generated.  Each  time 
a  process  is  scheduled  a  new  instance  (copy)  of 
the  process  is  created  and  executed.  Many 
instances  of  the  same  process,  therefore,  may 
be  executing  simultaneously,  though  perhaps 
at  different  stages  of  their  logic.  The  same  process 
may  also  execute  at  different  nodes  in  the  modeled 
system.  Thus,  several  instances  of  a  particular 
process  may  exist  at  every  node  in  a  modeled 
network  simultaneously.  But  it  is  only  necessary 
to  define  the  process  once. 

After  a  system  model  is  defined  by  specifying  its 
processes,  scenario,  loads,  resources,  legal  path 
table,  constants,  variables,  and  so  on,  the  model 
is  ready  to  be  exercised  using  the  Al. 

Analysis  Interface 

Using  the  Al,  the  analyst  typically  defines  plots 
and  system  variables,  runs  the  simulation,  and 
views  results  in  the  form  of  printed  statistics  or 
plots  (figure  9).  Several  runs  can  be  made  quickly 
to  determine  how  the  model  responds  to  various 
loading  conditions  and/or  capacity  parameters. 
Plots  for  a  particular  resource  or  message  type  are 
defined  by  choosing  from  a  table  entitled  “Attri¬ 
butes"  and  from  a  subsequently  displayed  table 
entitled  “Statistics."  An  example  of  a  resulting  plot 
is  also  shown  in  the  figure.  At  the  completion  of  a 
run,  plots  and  statistical  reports  may  be  viewed 
on  the  screen  and/or  printed.  The  Al  also  enables 
the  analyst  to  save  plots  for  subsequent  analysis 
and  use. 

Replot  Interface 

The  Rl  allows  the  user  to  retrieve  and  display 
plots  that  were  saved  in  the  Al.  With  the  RI,  plots 
from  several  different  runs  can  be  selected  and 
viewed  individually  or  overlaid  on  the  same  graph 
for  comparison  purposes.  The  Rl  also  provides  a 
housekeeping  function  for  plots  and  plot  defini¬ 
tions  by  providing  a  facility  for  deleting  them 
when  they  are  no  longer  needed. 

Library  Interface 

The  LI  enables  the  user  to  save  models  or  selected 
model  processes  on  either  a  user  or  system  library 
from  which  they  may  be  retrieved  and  used  to 


develop  new  models.  The  user’s  library  is  con¬ 
trolled  by  the  user,  who  may  add  or  delete  entries 
as  desired.  The  system  library  is  accessible  by  the 
user,  but  only  the  system  librarian  is  able  to  mod¬ 
ify  its  contents. 

A  set  of  A1SIM  processes  called  the  Message  Rout¬ 
ing  Submodel  (MRS)  resides  on  the  system  library. 
These  processes  may  be  inserted  into  a  model  to 
perform  message  routing  functions.  The  MRS  uses 


CALL 

SEND 

SUSPEND 

Control  execution  and  suspension  ot 

RESUME 

processes. 

WAIT 

CREATE 

DESTROY 

— 

Generate  and  eliminate  messages. 

ACTION 

— 

Consumes  time. 

EVAL 

Assign  values  to  variables  and  perform 

ASSIGN 

mathematical  and  statistical  functions. 

ALLOC 

DEALLOC 

RESET 

LOCK 

UNLOCK 

— 

Changes  status  of  resources. 

FILE 

FIND 

REMOVE 

— 

Manipulate  special  user-defined 
queues. 

BRANCH 

COMPARE 

ENTRY 

LOOP 

PROS 

TEST 

Control  flow  of  process  logic 

TRACE  H  Debugging. 


Table  2 

AISIM  Primitives 


node  and  link  resources  while  routing  messages 
through  a  network.  It  can  also  schedule  a  user- 
defined  function  at  a  message  destination  that 
could,  for  instance,  generate  and  route  an  acknowl¬ 
edgment  or  response  to  the  originator.  As  with 
any  library  entry,  the  MRS  may  be  used  as  is,  or 
it  may  be  modified  by  the  user. 

Hardcopy  Interface 

The  HI  provides  the  analyst  with  the  capability  of 
producing  hardcopies  of  the  process  flow  diagrams. 
This  interface  provides  the  commands  necessary 
to  print  the  desired  output  on  a  graphics  printer. 


The  HI  is  an  invaluable  tool  that  aids  in  the  docu¬ 
mentation  of  the  completed  model.  In  addition,  it 
facilitates  the  maintenance  of  model  documenta¬ 
tion.  As  processes  are  modified  the  process  dia¬ 
grams  are  automatically  updated,  and  revised 
hardcopies  may  be  produced  using  the  HI. 

Form  Input 

A  special  feature  of  A1S1M  is  its  use  of  forms  for 
data  entry.  Each  form  uses  labels  to  define  its 
fields.  The  fields  are  highlighted  with  the  “inverse- 
video”  feature  of  the  terminal.  As  an  additional 
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Scenario  Definition  Form 
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LOAD  DEFINITION 


Figure  8 

Load  Definition  Form 
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safeguard,  data  can  be  entered  only  into  the  high¬ 
lighted  fields.  Forms  help  the  modeler  enter  data 
correctly  and  ensure  that  all  necessary  data  is 
included.  They  facilitate  quick  model  building 
and  reduce  model  debugging  time. 

Summary 

The  simple,  powerful  functional  interfaces  of 
AISIM  enable  an  analyst,  with  essentially  no 
knowledge  of  programming,  to  quickly  and  effi¬ 
ciently  develop  system  performance  models.  The 
AISIM  commands  are  easy  to  learn  and  permit 
rapid  model  building  and  analysis.  Experience 
indicates  that  a  typical  user  can  learn  AISIM  within 
one  to  two  weeks,  then  start  to  build,  execute, 
and  analyze  models. 


Figure  9 
Model  Analysis  Cycle 
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Section  Three 


AISIM  Use 


This  section  gives  representative  examples  of  how 
AISIM  is  used  to  model  command,  control,  and 
communications  system  functions.  The  first  part 
discusses  modeling  examples  using  the  Dl,  and 
the  second  part  illustrates  how  the  AI  is  used  for 
execution  and  analysis  of  models,  including  exam¬ 
ples  of  plots  and  statistical  summaries. 


user.  This  table  defines  paths  between  pairs  of 
nodes  in  the  architecture,  and  is  referenced  by 
model  processes  in  routing  messages  through  the 
modeled  system. 


Design  Interface 


The  DI  is  entered  when  the  user  wishes  to  create 
or  modify  a  model.  Examples  of  the  three  major 
aspects  of  AISIM  model  design  (architecture  defi¬ 
nition,  function  specification,  and  system  load 
definition)  follow: 


Figure  1 1  is  an  example  of  a  loop  architecture 
created  using  the  AE.  In  this  network,  messages 
are  generated  at  hosts  (HI,  H2,  .  . .  H6)  and  sent 
to  Loop  Interface  Units  (LIUs)  represented  by 
B1 ,  . .  .  B6.  The  messages  are  then  transmitted 
via  the  loop  and  routed  to  the  next  LIU.  After  a 
processing  delay  each  message  is  routed  either  to 
the  attached  host  or  the  next  LJU,  depending  on 
its  destination. 


Architecture  Definition  The  Architecture 
Editor  (AE)  of  the  DI  is  used  to  define  a  system’s 
physical  architecture,  that  is,  the  layout  and  inter¬ 
connections  of  the  system’s  physical  resources: 
CPU,  disk  drive,  tape  drive,  channel,  and  so  forth. 
The  user,  employing  the  terminal’s  graphic  fea¬ 
tures,  creates  a  graphic  picture  of  the  system 
architecture  by  positioning  symbols  and  connec¬ 
tions  between  them.  The  14  symbols  provided  by 
AISIM,  together  with  their  mnemonic  labels,  are 
shown  in  figure  10.  The  analyst  also  may  assign 
attributes  and  attribute  values  to  specific  symbols 
to  characterize  physical  devices.  At  the  end  of  an 
AE  session,  a  Legal  Path  Table  can  be  generated 
either  automatically  by  AISIM,  or  manually  by  the 


In  this  example,  AISIM  automatically  generates 
resources  for  the  six  hosts,  the  six  LIUs,  and  the 
12  channels  defined  by  the  user  in  the  architecture 
diagram.  Full  duplex  channels  are  specified  by 
appending  \F  to  the  channel  name.  Thus,  the 
channels  connecting  the  hosts  and  the  LIU's  are 
full  duplex  channels.  The  user  may  define  and 
assign  a  set  of  attributes  to  a  resource.  For 
instance,  if  the  delay  of  messages  at  the  LIUs 
is  of  interest,  one  of  the  attributes  associated  with 
the  LIU  resource  could  indicate  the  processing 
delay  per  message  character.  If  this  value  is  defined 
as  a  global  constant  or  variable  it  can  easily  be 
changed  at  the  beginning  of  a  simulation  run. 

This  delay  value  could  then  be  used  by  a  process 
to  calculate  LIU  processing  delays  during  the 


Figure  10 

Architecture  Design 
Symbols 


1  1  2233445566? 

eses«s050ses0 


Loop  Architecture 
Example 


HOME  =  LETT  0 ,  UP  U 


course  of  the  simulation.  Subsequently,  statistical 
information  on  messages  could  be  compiled  auto¬ 
matically  during  the  run  and  viewed  at  a  later 
time. 

If  the  model  requires  an  LPT,  the  user  may  choose 
to  have  AIS1M  generate  the  LPT  at  the  end  of  the 
AE  session,  or  may  define  communication  paths 
using  AE  commands.  If  AISIM  generates  the  LPT 
and  ambiguities  are  encountered,  AISIM  will 
query  the  user  to  determine  the  desired  path. 

Each  entry  in  the  LPT  consists  of  a  FROM  node, 
a  TO  node,  a  NEXT  node,  and  a  CHANNEL.  The 
LPT  is  referenced  in  the  model  processes  with 
system  keywords.  Given  the  current  node  and  the 
destination  node  of  a  message,  for  example,  the 
LPT  is  then  referenced  with  the  appropriate  key¬ 
word  to  obtain  either  the  next  node  along  the 
message  path  (SNXTNODE)  or  the  channel  needed 
to  reach  that  node  (SCHANNEL). 


of  a  process  may  depend  on  the  availability  of 
resources.  Processes  can  represent  communica¬ 
tions  functions  as  the  following  examples  illustrate. 

Example  I  Messages  are  generated  at  several 
stations  and  transmitted  to  a  master  station.  The 
purpose  of  the  model  is  to  obtain  queuing  statistics 
for  the  transmission  lines  and  the  receiving  pro¬ 
cessor,  and  to  obtain  statistics  on  message  transit 
times. 

One  process  required  to  model  this  system  defines 
the  message  reception  and  processing  functions  at 
the  master  station.  To  create  this  process,  the  user 
enters  the  EDIT  PROCESS  command  specifying 
the  process’  name.  The  process’  parameters  are 
then  entered  in  the  process  form  displayed  by 
AISIM  (figure  12).  The  process  name  in  this  exam¬ 
ple  is  REC-MSG  and  the  master  station  node  is 


Function  Specification  The  Process  Editor 
(PE)  is  entered  from  the  Dl  level  when  the  analyst 
wishes  to  create  or  modify  a  process.  A  process 
defines  a  function  or  set  of  functions  of  the  mod¬ 
eled  system.  Each  process  is  composed  of  primi¬ 
tives  that  define  the  process  functions.  It  is  at  this 
level  that  resources  are  allocated  and  deallocated, 
time  is  consumed,  decisions  take  place,  and  so 
on.  Since  resources  are  limited  and  shared,  AISIM 
automatically  maintains  statistics  on  timing  and 
resource  contention  factors  during  model  execu¬ 
tion.  Processes  are  initiated  by  scenarios,  loads, 
and  by  other  processes.  Once  initiated,  execution 
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Figure  12 
Process  Form 


called  N0DE2.  Since  this  process  must  receive 
message  items  before  operations  can  begin,  it  is 
designated  as  a  parameter  passing  process  by 
entering  “PARM”  in  the  “START  BLOCK  TYPE’ 
field.  Figure  13  shows  the  additional  form  dis¬ 
played  by  AISIM  for  a  parameter  passing  process. 

In  this  case,  the  user  enters  the  name  “MSG”,  a 
pointer  to  the  message  being  passed  to  this  pro¬ 
cess.  AISIM  then  draws  the  basic  structure  of  the 
process  (figure  14). 

As  the  user  develops  the  process  by  adding  primi¬ 
tives,  AISIM  redraws  the  process  flowchart.  The 
appropriate  primitives  are  placed  in  the  flowchart 
using  the  PE  commands.  For  example,  to  generate 
the  first  operation  after  the  START,  the  command 
PLACE  ASSIGN  is  entered.  AISIM  displays  a  form 
for  the  ASSIGN  primitive  (figure  15)  in  which  the 
user  enters  parameters.  This  example  places  the 
LENGTH  attribute  of  MSG  into  a  local  variable 
called  MSG.LENG.  The  fully  developed  process 
(figure  16)  receives  a  message,  computes  process¬ 
ing  time  based  on  the  message  length,  allocates 
the  resource  required,  uses  the  resource  for  the 
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Parameter  Form 
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time  required  to  process  the  message,  destroys 
the  message,  and  deallocates  the  resource. 

The  entities  addressed  or  manipulated  by  the 
primitives  of  a  process  (resources,  constants, 
variables,  items,  etc.)  are  also  defined  by  the  user. 
For  instance,  in  the  process  just  defined,  an 
instance  of  an  item  called  MSG  must  have  been 
created  and  passed  to  this  process.  To  define  the 
format  or  template  for  an  item  the  EDIT  ITEM 
command  is  used.  The  item  form  (figure  17) 
shows  the  information  defining  MSG  entered  in 
the  appropriate  fields.  To  create  an  instance  of 
MSG,  the  CREATE  primitive  is  used  in  a  model 
process.  Figure  18  shows  the  form  used  for  defin¬ 
ing  a  resource.  For  resource  NODE 2,  one  unit  of 
the  resource  is  available  at  the  start  of  the  simula¬ 
tion.  The  number  of  units  available  during  the 
simulation  may  be  changed  by  the  process  logic. 
This  feature  may  be  used  to  simulate  a  resource 
failure  by  making  the  number  of  units  available 
equal  to  zero. 

Example  2  This  problem,  which  requires  model¬ 
ing  of  a  bus  communications  network  (figure  19), 
is  typical  of  a  class  of  problems  that  deal  with 
multiple  hosts  communicating  over  a  local  net¬ 
work.  In  this  example  HI, ...  H4  are  connected 
to  the  bus  through  Bus  Interface  Units  (BIUs) 
represented  by  B1 , . . .  B4.  Messages  generated  at 
each  host  are  routed  to  other  hosts  via  the  bus. 
Queuing  and  usage  statistics  are  to  be  generated 
for  the  bus,  channel,  and  processor  resources. 
Message  input  traffic  consists  of  data  requests 
generated  randomly  by  the  hosts. 

The  process  shown  in  figure  20  models  the  BIU 
functions.  The  BIU  receives  data  request  messages 
from  the  databus,  generates  acknowledgments  for 
each  message,  and  transfers  these  messages  to  the 
attached  host  for  processing.  The  process  is  desig¬ 
nated  a  parameter  passing  process  because  it  is 
to  be  called  from  another  process  and  passed  a 
pointer  to  a  message  (MSG).  The  GENACK  and 
SENDACK  processes  are  then  called  to  generate 
and  send  the  message  acknowledgment.  Primitives 
4,  5,  and  6  in  the  process  obtain  the  name  of  the 
BlU-to-host  channel  using  the  Legal  Path  Table 
(LPT).  Primitive  6  uses  a  system  keyword  ({CHAN¬ 
NEL)  that  references  the  LPT  to  determine  the 
next  channel  over  which  the  message  is  to  be 
transferred  given  the  current  node  (SCNODE)  and 


Figure  14 

Initial  Process  Flow  Diagram 


the  destination  node  (TO.NODE).  This  channel  is 
then  allocated  and  primitive  8,  an  ACTION  primi¬ 
tive,  specifies  the  amount  of  time  the  channel  is 
used  —  in  this  case  3  msec.  The  channel  is  then 
de-allocated  and  process  HOST  is  called  to  perform 
message  processing. 
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System  Loads  The  external  inputs  to  a  system 
are  modeled  using  the  scenario  and  load  entities. 
The  scenario  entity  specifies  the  length  and  num¬ 
ber  of  periods  of  the  simulation.  Periods  allow  the 
user  to  stop  the  simulation  to  alter  parameters  or 
inspect  results.  The  scenario  triggers  a  number  of 
loads  and/or  processes,  specifying  the  scheduling 
time  and  priority  for  each.  Load  entities  specified 
in  a  scenario  trigger  processes  according  to  the 
scheduling  method  specified.  A  load  is  normally 
used  to  schedule  processes  that  create  items  (mes¬ 
sages).  The  scheduling  method  may  be  any  one  of 
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Form  for  ASSIGN  Primitive 


Figure  16 
Complete  Process 
Flow  Diagram 


i 


2 


3 


4 


5 


b 


BEPLLOC  N0DE2 
1  UNITS 


3, 

\ 

/ 

J 


RELEASE  RESOURCE 


12  statistical  distributions,  including  Poisson  and 
exponential.  The  load  also  specifies  the  node  or 
nodes  in  which  the  scheduled  process  is  to 
operate. 


For  the  bus  communications  network  (example 
2),  message  input  traffic  for  the  modeled  network 
consists  of  data  requests  generated  by  the  hosts. 
Data  requests  are  generated  randomly  using  an 
exponential  distribution  (Poisson  arrival  pattern). 
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Figure  17 

Item  Definition  Form 


The  scenario  for  this  example  (BP2SCEN)  is  shown 
in  figure  21.  One  period  is  specified  with  a  length 
of  1 ,000,000  msec.  The  unit  of  time  for  this  model 
was  chosen  by  the  modeler  to  be  in  milliseconds. 
The  scenario  also  specifies  that  loads  LOADH1, . . . 
LOADH4  are  to  be  scheduled  at  time  zero  with  a 
priority  of  zero.  The  load  LOADH1  is  shown  in 
figure  22.  The  three  processes  specified  in  the 
load  create  messages  for  specific  destinations.  For 
example,  TOHOST2  creates  a  message  with  desti¬ 
nation  H2.  Thus,  the  load  specifies  that  a  maxi¬ 
mum  of  200  messages  destined  for  H2  is  to  be 
generated  with  the  time  between  messages  expo¬ 
nentially  distributed  around  a  mean  of  101,010 
msec. 
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Analysis  Interface 

AISIM  models  are  executed  using  the  AI.  If  more 
than  one  scenario  has  been  defined,  the  AI  asks 
the  user  for  the  scenario  to  be  used.  Once  the 
scenario  is  selected,  AISIM  translates  the  model 
definition  file  into  a  serial  input  file  and  error- 
checks  this  file.  If  errors  are  encountered  a  mes¬ 
sage  is  printed.  AISIM  identifies  errors  such  as 
inconsistency  in  data  types,  unresolved  addresses, 
and  undefined  terms.  A  file  is  listed  containing 
the  flagged  errors. 


Figure  18 

Resource  Definition  Form 
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Figure  19 
Bus  Architecture 


Commands  that  control  the  simulation  may  be 
used  both  before  and  during  model  execution. 
Prior  to  execution  the  user  may  specify  simulation 
data  to  be  plotted,  modify  variables  of  the  model, 
and  define  breakpoints  in  the  execution.  During 
execution  the  user  interfaces  with  the  model  at 
breakpoints  or  ends  of  periods  that  are  defined 
before  execution.  At  these  times  data  may  be 
plotted,  parameters  or,  breakpoints  changed,  and 
so  forth.  At  the  end  of  execution  data  may  be 
plotted  and  a  listing  obtained  of  all  statistics  pro¬ 
duced  by  the  model. 


Statistical  Summaries  Standard  statistical 
summaries  are  produced  automatically  by  A1SIM 
for  each  simulation.  During  model  execution 
AIS1M  automatically  collects  statistics  that  include 
resource  usage  (time  and  percent),  queue  times 
and  lengths,  transmission  times,  and  process 
timing.  Among  the  statistical  reports  produced 
are  a  resource  report  and  an  item  report. 
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AISIM  produces  a  resource  report  for  each  resource 
used  in  the  simulation.  During  model  execution 
AISIM  maintains  four  queues:  idle,  busy,  inactive, 
and  wait.  The  first  three  queues  are  really  “states" 
of  the  resource;  the  fourth  is  the  actual  queue  for 
the  resource.  During  the  simulation  the  idle  queue 
contains  the  number  of  resource  units  that  are 
available  but  unallocated,  the  busy  queue  contains 
resources  that  are  allocated,  the  inactive  queue 
contains  resources  that  are  unavailable,  and  the 
wait  queue  contains  processes  waiting  for  the 
resource. 
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Figure  20 

BIU  Data  Request  Process 


Figure  21 
Scenario  Definition  Form 
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Figure  23  shows  a  resource  report  for  a  resource 
called  CHANNEL.  The  resource  CHANNEL  may 
lie  a  link  over  which  messages  created  at  a  trans¬ 
mitting  node  are  sent  to  a  receiving  node.  The 
report  identifies  the  resource  attributes  in  the  row 
headings  and  the  individual  statistics  in  the 
column  headings.  The  report  shows  that  the 
resource  was  put  into  the  busy  state  180  times, 
which  corresponds  to  the  number  of  messages 
created.  Since  there  is  only  one  unit  of  the 
resource  CHANNEL,  the  mean  *  busy  indicates 
that  the  channel  was  used  66.3  percent  of  the 
time  for  message  transmission.  The  maximum  * 
waiting  indicates  that  the  maximum  queue  length 
for  this  resource  was  6  and  the  maximum  wait 
ti^e  shows  that  the  worst  case  wait  time  was 
104.975  msec. 


Figure  22 

Load  Definition  Form 


t  'UlIKl. t  t 

t  -OUMLt  I 

•<a nm  i 

•  I  DLL 

KtUdfcst  urn. 

1NIU  tHISY 

out  uk  i*usy 

•  HOST 
8USr  IIW 

•  INAL  U VI 

1  N  I  O  VA  l  I 

out  uk  wait 

•  WAIT  INC 

WA I  I  Tint 


10U 
1  HQ 


0  337 
L7S9L4 


0  663 
tJ  2SJ 


0  093 
17  8Sl 


<73 

894 


0  473 
tJ  912 


\  264 
22  884 


1  ODD 
VI  170 


6  000 
104  97S 


LURRlNlLY  ALLOCATED 

TO  PROCESSES.  NUNl 


PRUCtSSLS  CURRENTLY 
WAITING 


Figure  23 

CHANNEL  Resource  Report 
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Figure  24 
Item  Report 


The  item  report  provides  statistics  on  each  item 
(message  type)  used  in  the  model.  Figure  24  is 
an  example  of  an  item  report  for  a  model  that 
had  only  one  item  definition:  MSG.  The  report 
shows  the  number  of  items  that  were  created  and 
destroyed,  as  well  as  the  minimum,  maximum, 
and  average  time  an  item  was  in  the  system.  In 
this  example  the  number  of  items  called  MSG 
that  were  created  and  destroyed  was  180.  The 
statistics  on  a  message's  time  in  the  system  are  a 
function  of  the  processing  times  for  the  message 
and  the  wait  times  for  the  resources  needed.  For 
this  model  the  average  time  in  the  system  for 
items  called  MSG  was  53.17  msec;  the  maximum 
was  183.57  msec. 

Plot  Output  Before  execution  the  user  may 
request  plots  of  various  statistical  data.  These 
plots  can  be  displayed  and  printed  at  the  end  of 
the  simulation  or  at  the  end  of  a  simulation  period. 

Figure  25  shows  the  forms  used  to  request  a  plot 
for  resource  statistics.  The  "Attributes”  form  indi¬ 
cates  the  data  to  be  addressed  and  the  “Statistics" 
form  indicates  the  value  desired. 

Three  examples  indicate  the  kinds  of  data  that 
can  be  plotted.  The  current  number  of  processes 
waiting  for  the  resource  CHANNEL  is  plotted  in 
figure  26.  This  plot  gives  the  user  statistics  on 
the  dynamic  activity  of  the  wait  queue  for  this 
resource.  Figure  27  shows  plots  of  both  the  current 
time  and  cumulative  mean  time  in  the  system  for 
items  called  MSG.  Figure  28  shows  the  number  of 
MSG  items  in  the  system  at  any  given  time. 


System  Modeling  Examples 

“AISIM  Evaluation  —  Preliminary  Report"1  con¬ 
tains  five  examples  of  AISIM’s  use  for  communica¬ 
tions  system  modeling.  The  problems  modeled 
were  based  on  ESD  system  acquisitions  and  were 
used  in  the  evaluation  and  testing  of  AISIM. 

Summary 

AISIM  is  a  highly  interactive  discrete-event  sim¬ 
ulation  modeling  system.  It  provides  a  graphics 
capability  for  describing  a  modeled  system's  archi¬ 
tecture  and  functions,  a  simulation  capability  for 
analyzing  the  system,  a  reporting  system  for 
obtaining  performance  measures,  and  a  database 
for  storing  model  designs  and  definitions.  AISIM'S 
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Figure  25 

Plot  Definition  Forms  for  Resources 


Figure  26 
Wait  Queue  for  Resource 
CHANNEL 


16 


Figure  27 
Time  in  System  for  Item 
MESSAGE 
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Figure  28 

Number  in  System  for 
Item  MESSAGE 


interactive  organization  assists  the  user  in  several 
modeling  areas.  It  uses  interactive  graphics  to 
enable  the  analyst  to  “draw”  the  modeled  architec¬ 
ture  on  the  screen  and  to  describe  the  functional 
processes  that  operate  within  that  architecture. 
Each  modeled  process  is  represented  as  a  flow¬ 
chart  that  is  updated  and  drawn  automatically. 

The  architecture  diagrams  and  process  flowcharts 
provide  a  ready  source  of  model  documentation. 
AISIM  automatically  produces  standard  statistical 
summaries  and  allows  the  user  to  request  plots  of 
performance  statistics.  The  library  feature  allows 
the  user  to  save  model  designs  and  definitions  in 
a  library,  and  retrieve  them  or  portions  of  them 
for  developing  new  models. 

AISIM  is  an  easy-to-learn  tool  designed  for  direct 
use  by  an  analyst  as  a  workbench  for  investigating 
performance  impacts  of  design  alternatives  in  a 
short  period  of  time.  It  is  particularly  useful  during 
the  conceptual  phase  of  command,  control,  com¬ 
munications,  and  intelligence  system  acquisitions. 
Experience  to  date  indicates  that  AISIM  has  vast 
potential  for  application  to  a  wide  range  of  model¬ 
ing  problems. 


'H.  P.  Schultz.  S.  Natarajan,  and  J.  K.  Fryer,  “AISIM  Evaluation 
—  Preliminary  Report,"  ESD-TR-82-1 19.  Electronic  Systems 
Divison.  AFSC,  Hanscom  AFB,  MA,  Sept.  1981,  AD  A  113108. 
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